The IEEE 1394-1995 standard, “1394 Standard For A High Performance Serial Bus,” is an international standard for implementing an inexpensive high-speed serial bus architecture which supports both asynchronous and isochronous format data transfers. Isochronous data transfers are real-time transfers which take place such that the time intervals between significant instances have the same duration at both the transmitting and receiving applications. Each packet of data transferred isochronously is transferred in its own time period. An example of an ideal application for the transfer of data isochronously would be from a video recorder to a television set. The video recorder records images and sounds and saves the data in discrete chunks or packets. The video recorder then transfers each packet, representing the image and sound recorded over a limited time period, during that time period, for display by the television set. The IEEE 1394 standard bus architecture provides multiple channels for isochronous data transfer between applications. A six bit channel number is broadcast with the data to ensure reception by the appropriate application. This allows multiple applications to simultaneously transmit isochronous data across the bus structure. Asynchronous transfers are traditional data transfer operations which take place as soon as possible and transfer an amount of data from a source to a destination.
The IEEE 1394 standard provides a high-speed serial bus for interconnecting digital devices thereby providing a universal I/O connection. The IEEE 1394 standard defines a digital interface for the applications thereby eliminating the need for an application to convert digital data to analog data before it is transmitted across the bus. Correspondingly, a receiving application will receive digital data from the bus, not analog data, and will therefore not be required to convert analog data to digital data. The cable required by the IEEE 1394 standard is very thin in size compared to other bulkier cables used to connect such devices. Devices can be added and removed from an IEEE 1394 bus while the bus is active. If a device is so added or removed the bus will then automatically reconfigure itself for transmitting data between the then existing nodes. A node is considered a logical entity with a unique address on the bus structure. Each node provides an identification ROM, a standardized set of control registers and its own address space.
The IEEE 1394 standard defines a protocol as illustrated in FIG. 1. This protocol includes a serial bus management block 10 coupled to a transaction layer 12, a link layer 14 and a physical layer 16. The physical layer 16 provides the electrical and mechanical connection between a device or application and the IEEE 1394 cable. The physical layer 16 also provides arbitration to ensure that all devices coupled to the IEEE 1394 bus have access to the bus as well as actual data transmission and reception. The link layer 14 provides data packet delivery service for both asynchronous and isochronous data packet transport. This supports both asynchronous data transport, using an acknowledgement protocol, and isochronous data transport, providing real-time guaranteed bandwidth protocol for just-in-time data delivery. The transaction layer 12 supports the commands necessary to complete asynchronous data transfers, including read, write and lock. The serial bus management block 10 contains an isochronous resource manager for managing isochronous data transfers. The serial bus management block 10 also provides overall configuration control of the serial bus in the form of optimizing arbitration timing, guarantee of adequate electrical power for all devices on the bus, assignment of the cycle master, assignment of isochronous channel and bandwidth resources and basic notification of errors.
An application programming interface (API) for applications using the IEEE 1394 standard serial bus has been developed by Skipstone for enabling the application to use the IEEE 1394 bus for data transfers. With their API, Skipstone includes a manual entitled “The SerialSoft IEEE 1394 Developer Toolkit,” available from Skipstone, Inc., 3925 West Braker Lane, #425, Austin, Tex. 78759. Skipstone defines their API as a collection of programming calls to be used by the application to manage data being written to and obtained from a device over an IEEE 1394 bus. To initialize an isochronous transfer, several asynchronous data transfers may be required to configure the applications and to determine the specific channel which will be used for transmission of the data. Once the channel has been determined, buffers are used at the transmitting application to store the data before it is sent and at the receiving application to store the data before it is processed. In a transmitting application, the Skipstone API actively manages the transfer of data from the appropriate portion of the appropriate buffer onto the bus structure, during the appropriate time period. In a receiving application, the Skipstone API actively manages the reception of data from the bus structure, storing the data in the appropriate portion of the appropriate buffer and the processing of the data in the appropriate time period.
During asynchronous data transfers, the Skipstone API actively manages the required transactions to complete the data transfer. During an asynchronous incoming write transaction, the application provides a buffer to the API, mapped to a certain area of the 1394 bus address space. As write transactions arrive at the API, their data is written to the buffer. During an asynchronous incoming read transaction the application is responsible for making sure that the buffer contains useful information. The 1394 bus driver then reads the data from the buffer at the requested address when the read transaction arrives. For both write and read transactions, the Skipstone API actively manages and generates each necessary transaction. For example, if a block of data is being transferred to the application, of a size requiring multiple transactions, the Skipstone API requires the application to describe each 1394 transaction necessary to complete the transfer of the block of data. This consumes significant overhead by the processor of the application as well as the full attention of the API during an asynchronous data transfer operation.
The Skipstone API supports isochronous data transfer operations in a similar way. Specifically, the application must describe each isochronous packet to the Skipstone API. The Skipstone API then transmits each packet at the proper time. This requires significant processor overhead and thereby prohibits efficient processing of the isochronous data by the application.
A block diagram of an exemplary IEEE 1394-1995 serial bus network including a computer system and a video camera is illustrated in FIG. 7. The computer system 200 includes an associated display 202 and is coupled to the video camera 204 by the IEEE 1394-1995 serial bus cable 206. Video data and associated data are sent between the video camera 204 and the computer 200 over the IEEE 1394-1995 serial bus cable 206.
A block diagram of the internal components of the computer system 200 is illustrated in FIG. 8. The computer system 200 includes a central processor unit (CPU) 244, a main memory 230, a video memory 246, a mass storage device 232 and an IEEE 1394-1995 interface circuit 228, all coupled together by a conventional bidirectional system bus 234. The interface circuit 228 includes the physical interface circuit 242 for sending and receiving communications on the IEEE 1394-1995 serial bus. The physical interface circuit 242 is coupled to the camera 204 over the IEEE 1394-1995 serial bus cable 206. The system bus 234 contains an address bus for addressing any portion of the memory 230 and 246. The system bus 234 also includes a data bus for transferring data between and among the CPU 244, the main memory 230, the video memory 246, the mass storage device 232 and the interface circuit 228.
The computer system 200 is also coupled to a number of peripheral input and output devices including the keyboard 238, the mouse 240 and the associated display 202. The keyboard 238 is coupled to the CPU 244 for allowing a user to input data and control commands into the computer system 200. A conventional mouse 240 is coupled to the keyboard 238 for manipulating graphic images on the display 202 as a cursor control device.
A port of the video memory 246 is coupled to a video multiplex and shifter circuit 248, which in turn is coupled to a video amplifier 250. The video amplifier 250 drives the display 202. The video multiplex and shifter circuitry 248 and the video amplifier 250 convert pixel data stored in the video memory 246 to raster signals suitable for use by the display 202.
IEC-61883 is a ratified international standard for the transport of audio/video command requests and responses. This standard uses the concept of plugs and plug control registers to manage and control the attributes of isochronous data flows. It should be noted that plugs do not physically exist on an audio/video device, but a plug is used to establish an analogy with existing audio/video devices where each flow of information is routed through a physical plug.
An isochronous data flow flows from one transmitting device, such as the video camera 204, to one or more receiving devices, such as the computer system 200, by transmitting isochronous packets on an isochronous channel of the IEEE 1394-1995 serial bus. Each isochronous data flow is transmitted to an isochronous channel through one output plug on the transmitting device and is received from that isochronous channel through one input plug on the receiving device.
The transmission of an isochronous data flow through an output plug is controlled by an output plug control register (oPCR) and an output master plug register (oMPR) located on the transmitting device. The output master plug register controls all attributes that are common to all isochronous data flows transmitted by the corresponding transmitting device. The output plug control register controls all attributes of the corresponding isochronous data flow that are independent from attributes of other isochronous data flows transmitted by the transmitting device.
The reception of an isochronous data flow through an input plug is controlled by an input plug control register (iPCR) and an input master plug register (iMPR) located on the receiving device. The input master plug register controls all attributes that are common to all isochronous data flows received by the receiving device. The input plug control register controls all attributes of the corresponding isochronous data flow that are independent from attributes of other isochronous data flows received by the receiving device.
An isochronous data flow can be controlled by any device connected to the IEEE 1394-1995 bus by modifying the corresponding plug control registers. Plug control registers can be modified through asynchronous transactions on the IEEE 1394-1995 bus or by internal modifications if the plug control registers are located on the controlling device.
To transport isochronous data between two audio/video devices on the IEEE 1394-1995 bus, it is necessary for an application to connect an output plug on the transmitting device to an input plug on the receiving device using an isochronous channel. The relationship between one input plug, one output plug and one isochronous channel is called a point-to-point connection. A point-to-point connection can only be broken by the application that established it. An application can also just start the transmission or reception of an isochronous data flow on its own device by connecting one of its output or input plugs respectively to an isochronous channel. The relationship between one output plug and one isochronous channel is called a broadcast-out connection. The relationship between one input plug and one isochronous channel is called a broadcast-in connection. Broadcast-out and broadcast-in connections are collectively called broadcast connections. A broadcast connection can be established only by the device on which the plug is located, but it can be broken by any device.
A plug has four possible states. These states are idle, ready, active and suspended. A plug is either on-line or off-line. Only a plug that is on-line is capable of transmitting or receiving an isochronous data flow. A plug will be off-line, for example, if it relies on resources that are temporarily unpowered or otherwise unavailable. A plug to which no connections exist is referred to as unconnected. A plug to which one or more connections exist is referred to as connected. A plug which is connected and on-line is in the active state. Only an active plug shall transmit or receive an isochronous data flow except in the case of a bus reset where the isochronous data flow is resumed immediately after the bus-reset.
A diagram of the software layers implemented within an IEEE 1394-1995 capable computer system 200 is illustrated in FIG. 9. The application layer 280 includes at least one application 286. The driver layer 282 includes the 1394 Protocol driver 288, the 1394 Bus Class driver 290 and the 1394 Port driver 292. The 1394 Protocol driver 288 performs commands that allow the application to communicate with other devices or applications across the IEEE 1394-1995 serial bus, such as the video camera 204. The 1394 Bus Class driver 290 is responsible for communications sent and received over the IEEE 1394-1995 serial bus. The 1394 Port driver 292 is a hardware interface driver. The hardware layer 284 includes the 1394 PCI Interface module 294 which provides the interface between the IEEE 1394-1995 serial bus and the system bus 234 within the computer system 200. The 1394 PCI Interface module 294 is coupled to the physical interface 296 of the video camera 204 by the IEEE 1394-1995 serial bus.
Such a stack of software layers as illustrated in FIG. 9 is currently provided by Microsoft within the Windows™ 98 operating system. The application programming interface (API) provided within this current implementation included within the Windows™ operating system provides no feedback to an application relating to activities that occur on a plug. For example, if another device on the IEEE 1394-1995 serial bus changes the plug's connection or the isochronous data flow for a plug, these state changes are not reported by this API to the upper layer software which is using the plug, causing the upper layer software to fall into an unknown working state. This API also does not allow upper layer software clients to explicitly establish connections between other devices on the IEEE 1394-1995 serial bus. This API will also not allow a client application to create the actual connection and manage the type of connection between the PC and the external device.
What is needed is an API that provides automated generation of transactions necessary to complete a data transfer, without requiring supervision by the API and the processor of an application. What is further needed is an API which implements isochronous transfer features of the IEEE 1394 standard bus structure very efficiently, permitting a high degree of hardware automation, if needed by the application.